System and method for integrating entities via user-interactive rule-based matching and difference reconciliation

ABSTRACT

A system and method for integrating entities using a graphic user interface (GUI) to provide user-interactive rule-based matching and difference reconciliation. In one aspect, a system for integrating entities employs a combination of default matching and reconciliation approaches and user tailoring to generate a composite entity from one or more input entities using a set of composition rules. The set of composition rules comprises a combination of default rules, as well as rules that represent user interactions that are performed via a graphical user interface when the user edits a composite result. The rules are captured and then stored persistently when the user requests that the composition be saved, such that the rules may be retrieved during a subsequent editing session associated with the same inputs. If the inputs change, the integration process (as specified by the rules) can automatically handle many changes. It is only when changed elements of the input are, or need to be, subject to specific rules that additional tailoring may be required.

BACKGROUND

1. Technical Field

The present invention relates generally to software development toolsand, more particularly, to a system and method for integrating entitiesusing a graphical user interface (GUI) to provide user-interactiverule-based matching and difference reconciliation.

2. Description of Related Art

Typically, during software development, there are many situations whereentities (e.g., objects, messages, or data) must be integrated, eventhough their detailed content is different (e.g. different data fields,types, aggregations, etc.). For example, during the development ofobject-oriented applications, common base classes may be factored out byanalyzing the input classes to find “matching” data and methods whichcan be combined and then moved to the base class. Composite objects areformed by aggregating one or more input (component) classes that areexposed through a “combined” interface of the composite. Moreover, inmessaging systems, multiple messages from different sources might haveto be combined to form a single, integrated message.

Entities typically consist of many elements. When integrating entities,some elements of the entities to be integrated might match (i.e., theyrepresent the same thing in the different representations) while othersmight not. The matching criteria used for integrating entities can varygreatly, ranging from simple element-name matching, to more complicatedscenarios in which syntactically different input entities may actuallyrepresent the same thing. Once matching elements of the input entitieshave been identified, any differences between them must be reconciled,and then these reconciled elements are integrated to form the compositeentity.

A similar, and even more common, situation for integrating entities iswhere entities must be shared by, or passed between, applications, butwhere the different applications have different expectations regardingthe detailed content of such entities. This process is referred to byvarious names, depending on the nature of the entities involved. Forexample, if the entities are objects that communicate throughinterfaces, this process called “interface mapping” or applicationprogram interface (API) mapping. If the entities are messages or data,the process is called “message mapping” and “data mapping,”respectively. In these cases, integration is required not to produce acomposite, but to map inputs to outputs. Indeed, the growing popularityof XML (Extensible Markup Language) as an interchange form has broughtthis issue to the forefront: XML dictates a common format, but notcommon content. Consequently, the integration of content elements iscritical to realizing free interchange.

Conventionally, the process of integrating entities typically comprisestwo steps. The first step of the integration process typically involvesexamining the definitions of the entities to be integrated, anddetermining which of their elements match and how their differences canbe reconciled. The second step of the integration process involves theexecution of the integration in accordance with the determination madein the first step, which involves, for example, actually callingfunctions, or building integrated messages or data from actual inputmessages or data.

The first and second steps of the integration process typically occur atdifferent times, referred to herein as “development-time” and“run-time,” respectively. “Development-time” refers to the time when thefirst step of the integration process is performed. For example, in thecase of message integration, the first step occurs when developersexamine definitions of messages that must be integrated, while a systemis being developed or modified. On the other hand, the second step ofthe integration process typically occurs during “run-time,” (e.g., inthe case of message integration, the time when actual messages are beingsent and received). It is to be understood, however, that there arecases where “development-time” and “run-time” occur simultaneously. Forexample, if integration were used in a programming environment to helpfactor out base classes, as described above, the resulting base classeswill actually be produced right after the user specifies how to do so.

Conventionally, the “development-time” task of matching commondefinitions of elements, reconciling their differences and determininghow to produce an integrated result is generally a manual operation withvery little, if any, tool support. For example, some existingdevelopment-time matching software tools are limited in that they onlydisplay and help users visualize the input elements while the usermatches and reconciles each input element, one by one (i.e., usertailoring), but do not support mechanisms for performing automaticmatching of elements.

In addition, other conventional software tools (or builders) that areused for software development, in general (e.g., building UML (UnifiedModeling Language) designs), provide a combination of automaticprocessing when possible, as well as user tailoring. These systems,however, may be configured such that all or some of the informationresulting from user tailoring is lost when the tool is run again, whichis known in the art as the “round-trip” problem. The diagram of FIG. 2Aillustrates a general approach utilized by some conventional softwarebuilder tools. With a conventional software tool, the result (denoted by“R”), which is generated by processing input components 1 ₁ and 1 ₂, forexample, is typically stored persistently, when the user is satisfiedwith the result. Although the result R is derived from processing theinput components, it is nevertheless treated like an unrelated entity.Consequently, if the input components comprising the result R areslightly modified requiring some minor editing of the result R, theprevious result must be analyzed in order to determine how the result Rwas derived from the inputs and what user tailoring was performed toobtain the result, which is difficult and sometimes virtuallyimpossible. Alternatively, a new result can be produced by processingthe modified inputs using the tool, discarding the previous result(including all the work the user put in to producing it), which isburdensome to the user.

Accordingly, there is a need for a software development system andmethod which supports both automatic and user guided rule-based matchingand reconciliation for integrating one or more entities, whereby thematching/reconciliation rules are stored such that they can be recalledand applied during a subsequent editing session when the input entitieschange or a new composite entity of the inputs is desired.

SUMMARY OF THE INVENTION

The present invention is directed to a system and method for integratingentities using a graphical user interface (GUI) to provideuser-interactive rule-based matching and difference reconciliation.

In one aspect of the present invention, a system for integratingentities employs a combination of default matching and reconciliationapproaches and user tailoring to generate a composite entity from one ormore input entities using a set of composition rules. The set ofcomposition rules comprises a combination of default rules, as well asrules that represent user interactions that are performed via agraphical user interface when the user edits a composite result. Therules are captured and then stored persistently when the user requeststhat the composition be saved, such that the rules may be retrievedduring a subsequent editing session associated with the same inputs. Ifthe inputs change, the integration process (as specified by the rules)can automatically handle many changes. It is only when changed elementsof the input are, or need to be, subject to specific rules thatadditional tailoring may be required.

In another aspect, the GUI is configured such that when a user selects aresult element, the GUI will highlight the input elements that wereintegrated to form the selected result element. Similarly, when the userselects an input element, the GUI will highlight each result element itcontributes to.

In another aspect, the user can select some specific inputs, and specifythat they should match, or specify that matched elements should not bematched.

In another aspect, a dependency mechanism is employed to track whichspecific result elements are affected by a recorded rule in the ruleset, as well as the manner in which the rule affects such resultelements, such that the dependency information can be used toautomatically disable earlier rules which conflict with subsequentrules, and allow the user to manually disable undesired rules. Inparticular, the dependency mechanism supports multi-level undo/redo andthe direct manipulation of the rules (i.e. user actions). For example,an explicit rule that the user may have applied, such as deleting anelement from the result, could be undone by simply removing the “deleterule” from the rule set. This includes, for example, either performingan “undo” operation or selecting the specific “delete rule” from the setand indicating that it should be removed.

These and other aspects, features and advantages of the presentinvention will be described and become apparent from the followingdetailed description of preferred embodiments, which is to be read inconnection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system for integrating entities inaccordance with an embodiment of the present invention;

FIG. 2A is a general block diagram illustrating a process for producinga composite result in accordance with the prior art;

FIG. 2B is a block diagram illustrating a process for producing acomposite result in accordance with one aspect of the present invention;

FIG. 3 is a diagram illustrating a run-time process for integratingentities, which may be implemented in connection with the presentinvention;

FIG. 4 is a diagram illustrating another run-time process forintegrating entities, which may be implemented in connection with thepresent invention;

FIG. 5 is a flow diagram illustrating a method for integrating entitiesin accordance with one aspect of the present invention;

FIG. 6 is a flow diagram illustrating a method of operation of thematching/reconciliation engine of FIG. 1; and

FIG. 7 is an exemplary graphical user interface which may be employedfor integrating entities in accordance with one aspect of the presentinvention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

It is to be understood that the present invention may be implemented invarious forms of hardware, software, firmware, special purposeprocessors, or a combination thereof. Preferably, the present inventionis implemented in software as an application program tangibly embodiedon a program storage device. The application program may be uploaded to,and executed by, a machine comprising any suitable architecture.Preferably, the machine is implemented on a computer platform havinghardware such as one or more central processing units (CPU), a randomaccess memory (RAM), and input/output (I/O) interface(s). The computerplatform also includes an operating system and microinstruction code.The various processes and functions described herein may either be partof the microinstruction code or part of the application program (or acombination thereof) which is executed via the operating system. Inaddition, various other peripheral devices may be connected to thecomputer platform such as an additional data storage device and aprinting device.

It is to be further understood that, because some of the constituentsystem components and method steps depicted in the accompanying Figuresare preferably implemented in software, the actual connections betweenthe system components (or the process steps) may differ depending uponthe manner in which the present invention is programmed. Given theteachings herein, one of ordinary skill in the related art will be ableto contemplate these and similar implementations or configurations ofthe present invention.

Referring now to FIG. 1, a block diagram illustrates a system forintegrating entities in accordance with an embodiment of the presentinvention. The system 10 includes a matching/reconciliation (MR) engine11 which, during development-time (or “editing session”), receives asinput one or more input definitions 12, where each input definition 12describes a type of element comprising an entity. The MR engine 11 thengenerates result definitions 13 which, for example, describe elementtypes of a composite entity. It is to be understood that the MR engine11 may be configured to receive and process actual run-time elements ofone or more input entities to produce output elements of the compositeentity. As such, the term “element” may be used herein to collectivelyrefer to both run-time elements and development-time definitions ofelements.

The MR engine 11 will generate the result definitions 13 for given inputdefinitions 12 by applying a corresponding rule set 14 comprising one ormore matching and reconciliation (composition) rules, which specify themanner by which to combine the elements of the input entities and, insome instances, reconcile the differences. The basic underlying theoryof the composition rules and the manner in which they are applied by theMR engine 11 is described in detail in “Specifying Subject-OrientedComposition” by H. Ossher, et al., Theory and Practice of ObjectSystems, Vol. 2 #3, pp. 179-202, Wiley, 1996, which is fullyincorporated herein by reference. The result definitions 13, as well asthe input definitions 12, are displayed using a proprietary GUI 15,which may be configured based on the type of application in which thepresent invention is employed.

As explained in further detail below, during each editing session, arule set 14 is recorded and associated with a given set of inputs.Specifically, default matching and reconciliation may be initiallyperformed automatically by the MR engine 11 using rules defining adefault overall composition style (algorithm) selected by the user viathe GUI 15. The result definitions 13 (produced by applying the defaultrules) is then displayed to the user using the GUI 15, which shows boththe inputs and the result produced. If the user is not satisfied withthe result 13 that is generated using the initial default rules(composition style), the user can tailor the result 13 by performing oneor more interactions via the GUI 15. Such user-interactions include, forexample, selecting a different default matching and reconciliationmethod (either for the entire output result or for selected parts ofit), specifying a particular match between desired input elements whichwere not initially matched by the MR engine 11, retracting a match thatwas found by the MR engine 11, adding desired elements to, or deletingdesired elements from, the displayed result 13, renaming elements in thedisplayed result 13, and/or specifying certain transformations that areneeded to reconcile input elements.

Referring now to FIG. 7, a diagram illustrates an exemplary GUI whichmay be employed for integrating entities in accordance with one aspectof the present invention. It is to be understood that the GUI of FIG. 7is presented for illustrative purposes only and that the presentinvention may be implemented in any computer programming environment ordata processing system (e.g., object-oriented and database applications)in which integration or composition of entities is desired. It is to befurther understood that such applications may employ one or more GUI'sthat are suitable for the corresponding application. The GUI of FIG. 7is illustrative of a GUI which may be employed in a system configuredfor generating composite business objects, such as InternationalBusiness Machines' (IBM) WebSphere™ system. The WebSphere™ system is amiddleware product that can be used to design, develop and deploydistributed object-oriented (O-O) applications implementing “business”objects, for example. Business objects are O-O objects (in C++ code, forexample) which comprise methods that are suitable for businessapplications (e.g, “Employee” “Customer”, “Account” objects). Thepresent invention may be employed in this system to assist a user toautomatically implement an interface of a desired composite object interms of the interfaces of the component objects without having tomanually generate the code for the composite object from scratch.

As shown in FIG. 7, the illustrative GUI comprises and “input panel” 70for displaying one or more input business objects (e.g., CheckingAccount and Savings Account) which are selected by a user forintegration. The illustrative GUI may also include a “composition rules”item selection field 72 which allows the user to select a desiredoverall default composition style (i.e., default matching algorithms).Moreover, the illustrative GUI comprises an “output panel” 71 fordisplaying the result composite business object (e.g., Account Group)(which is synthesized from the input objects). The user can select andhighlight an element in the result (e.g., by pointing and clicking withthe mouse), and the input element(s) that were integrated to form theselected output element are highlighted also. This is illustrated inFIG. 7 with regard to the “debit” method. Similarly, the user can selectan input element, and the GUI will highlight all output elements intowhich the selected input element was integrated.

The user can refine the output result by interactively editing thedisplayed elements. For example, as shown, the illustrative GUI includesfunctions such as “Equate”, “Rename”, “Split” and “Delete”. The “Equate”function may be utilized to combine (match) input elements of the inputobjects that were not combined using the default composition rules. Thisis performed by highlighting desired elements of the input objects andselecting the equate function, and the output object will be updatedaccordingly. In addition, the “split” function may be utilized tounmatch elements that were combined. This is performed by highlightingthe desired output element and selecting the “split” function. Inaddition, certain elements may be deleted or renamed by highlightingdesired elements and selecting the “delete” and “Rename” function,respectively.

It is to be appreciated that during the editing session, notwithstandingthat each user-interaction appears to be directly editing or modifyingthe output result 13, what is actually occurring is that each userinteraction is changing the underlying composition that is used by theMR engine 11 to derive the output result definitions 13 from the inputdefinitions 12. In particular, for each user interaction, a compositionrule or set of composition rules is recorded and stored in the rule set14 for the given inputs 12. Each recorded rule is associated with itscorresponding result element(s) so as to remember which elements therules refer to.

The process of generating and recording a rule (or set of rules) foreach user-interaction during the editing process provides a significantadvantage over the prior art method which, as described above withreference to FIG. 2A, saves the result rather than rules used togenerate the result. Advantageously, in accordance with the presentinvention, the composition rules that are generated and recorded duringan editing session are applied to the inputs whenever the result isrequired. FIG. 2B illustrates the approach used in accordance with thepresent invention, whereby the set of rules (RS) that are generated inaccordance with user tailoring are stored (rather than the result).These rules represent the transformation function (F_(RS)) that isapplied by the MR engine 11 to transform the inputs to produce therequired result. Rather than capturing the end result, the presentinvention is employed to capture the information representing therelationship between the result and the original inputs. Because theresult is in fact a function of the matched inputs, it is advantageousto maintain the transformation function rather than the result itself,especially when iterative matching is required. Advantageously, bysaving rules instead of the result, the set of rules can be applied toaltered and/or additional inputs. This approach ensures that, even whenthe inputs change, a result is produced for the user to examine andtailor. In many cases, it is likely to be correct, or close to correct.This is primarily because the present invention employs (as described infurther detail below) default matching and reconciliation mechanismsthat, when applied to the modified inputs, can automatically handle manyof the input changes. It is only when changed parts of the inputs are,or need to be, subject to specific rules, that additional tailoring isneeded. This is in contrast to the systems (e.g., builders) that employcombinations of automatic processing and user tailoring, but lose all,or part of, the user tailoring if inputs change; this is known as the“round-trip” problem. The approach of the present invention mitigates(or eliminates) the “round-trip” problem, by applying the previouslysaved rules during a subsequent editing session of the same inputs (i.e.the same file with modified input elements) to produce the desiredresult, or at least provides a better starting point from which to beginfurther tailoring.

As explained above, during an editing session, the user may perform manyinteractions, each of which specifies one or more new rules to be addedto the rule set. Consequently, later recorded rules might conflict insome way with earlier recorded rules. In such cases, the later rulesshould prevail. To accomplish this, the present invention advantageouslyemploys a dependency mechanism in the rule set 14 which tracks how eachrecorded rule (in the corresponding rule set) affects a particularresult definition 13, or a set of result definitions, and in whatparticular way. For example, a given rule might change the name of adefinition, or set some particular attribute to a particular value. Inthis manner, before executing a particular rule, the MR Engine 11 cananalyze the dependencies among the rules to determine whether any laterrule in the rule set affects the same result definition(s) in a relatedway (e.g., also changing the name, or setting the same attribute). Ifso, the earlier rule is automatically disabled.

This approach to determining inter-rule dependencies and disabling ruleshas other important advantages. For example, the well-known function“Undo” may be implemented by disabling the last currently-enabled rule.A different flag value may be used to record the manner in which a givenrule is disabled. For instance, one flag value may be used to indicate arule that is disabled by the “undo” function, whereas another flag valuemay be used to indicate an earlier contradicting rule that has beendisabled automatically. In addition, the function “Redo” may beimplemented by enabling the last rule that was disabled by the “Undo”function. It is to be further appreciated that the GUI 15 can beconfigured to display the current rule set, with disabled rulesindicated (and differentiated by the corresponding flag values). Thisfeature allows the user to explicitly disable or enable individual rules(except that automatically disabled rules cannot be manually enabled,because they would just end up being disabled again by the processabove). This is a more flexible approach to the “undo” function (than iscommon) which is realizable due to the fact that rules can be related toexplicitly affected result definitions, and all dependencies betweenrules can be determined on this basis. Another advantage is thatdisabled rules can be removed from the rule set. This reduces the sizeof the rule set and improves the efficiency of the MR Engine 11(although the undo/redo capability is lost with respect to the removedrules).

As explained above, when an editing session is complete and the userexits, the rule set 14 is saved, along with some information about theinputs 12. When the user initiates another session to, e.g., edit theresult for the unchanged inputs or edit the result, if needed, tocompensate for changes in the input, the user can restore the previouslyrecorded rule set to reapply the rules to the inputs. If the details ofthe inputs did not change in the interim, the result definition 13 willbe the same. If the inputs did change, however, some of the details ofthe rules in the rule set may be incorrect or not applicable. Forinstance, one or more rules might refer to elements in the inputs thatno longer exist. If so, the system may be configured to automaticallyremove such references from the rules. If a rule no longer has anyeffect, the system may be configured to automatically disable the rule.In addition, certain rules may refer to existing elements, but may be nolonger be correct. In this instance, the user will determine whethercertain rules are incorrect. It is to be appreciated that regardless ofthe change in the input, the previous rules may be applied (unless ofcourse the user desires to begin a new rule set by initially applyingthe default composition rules) and the result presented to the user, whocan make changes by further interactions that add more rules, and/or bymanually disabling some rules.

After an editing session that results in result definitions 13 that aresatisfactory to the user, the user can request generation of the script16, which is generated by the MR engine 11. The script 16 may be aprogram or a piece of program that, when executed at run time, willperform the integration (produce the result) determined by the user. Asshown in FIG. 3, the script 16 accepts inputs 31 and integrates them toproduce output 32. The inputs must all conform to the input definitions12 so that the output 32 will conform to the result definition 13 (FIG.1).

Alternatively, referring to FIG. 4, the script 16 can be data (tables)that are used by an integrator 40 at run time to perform theintegration. At run time, the integrator 40 accepts a number of inputs31 and the script 16, and produces an output 32. Again, if the inputs 31all conform to the input definitions 12, that the output 32 will conformto the result definition 13.

Referring now to FIG. 5, a flow diagram illustrates a method forintegrating entities in accordance with one aspect of the presentinvention. It is to be understood that the method of FIG. 5 illustratesan editing session that the user performs during “development time” togenerate a script for integrating one or more entities (i.e., generatinga script for mapping one or more inputs to an output result). Initially,the system will receive one or more inputs from the user (step 500),where each input represents an entity. As indicated above, each inputcomprises either definitions that describe elements of a given entity,or the actual run-time elements of a given entity. If the user desiresto continue a previous MR editing session for the given inputs using apreviously saved rule set (affirmative decision in step 501), the storedrule set may be retrieved from memory (step 502). If there is nopreviously stored rule set (or if the user wants to generate a new ruleset) for the given inputs (negative decision in step 501), the rule setwith the default composition style will be initialized (step 503).

When the desired initial rule set has been selected by the user, the MRengine will apply the selected rule set to the inputs (step 504) and theresult will be output (e.g., displayed) (step 505). If the user issatisfied with the output result (affirmative result in step 506), theuser will select a quit request to end the editing session and the ruleset for the given inputs will be saved (step 507), and a script will begenerated (step 513). If, on the other hand, the user is not satisfiedwith the result (negative result in step 506), the user can proceed toedit the output result through a user interaction (step 508). As statedabove, the user interaction may include, for example, selecting adifferent default matching and reconciliation method (either for theentire output result or for selected parts of it), specifying a matchbetween input elements that were not matched by the MR engine using thecurrently existing rules, retracting a match that was found by the MRengine, adding elements to or deleting elements from the result,renaming elements in the result, and/or specifying transformationsneeded to reconcile input elements. Each user interaction (which editsthe output result) specifies one or more new rules which are added tothe rule set to produce a modified rule set (step 509). As noted above,the user perceives this process as editing the output result, butunderneath it is actually creating and refining the set of MR rulesneeded to produce the required result.

For each user interaction which generates a rule (or rules) that isadded to the rule set, a determination is made (based on the rule) as towhether an optimization process can be applied (step 510). Thisdetermination is made in accordance with predetermined criteria based onthe type of rule(s) generated and the affect of the rule(s) on theentire rule set. For instance, if the user interaction is a request toapply a different default composition style to the input elements, sucha change would have such a profound impact on the output that the entirerule set would be reprocessed by the MR engine 11. On the other hand, arequest to rename an output element may not have such a profound affecton other rules and output elements so that it may be executed locally.Therefore, if optimization is allowed (affirmative determination in step510), the MR engine can operate locally for the new rule, whereby therule is executed incrementally to update the existing result definition(step 511) and then display the modified result (step 505). Ifoptimization is not allowed (negative determination in step 510), thenthe MR engine will execute the entire rule set (step 512) and then themodified result is displayed (step 505). Advantageously, optimizationprovides the same result with greater efficiency.

Referring now to FIG. 6, a flow diagram illustrates a method ofoperation of the MR engine (step 504 and 512, FIG. 5) in accordance withone aspect of the present invention. As noted above, the MR engineoperates to match and reconcile the inputs by executing each rule (inthe set of rules) in sequence each time the result needs to be generatedor displayed. Initially, the MR engine 11 will initialize the result(step 600), and reset all flag values that correspond to rules that havebeen automatically disabled (step 601). This is to ensure that any rulesthat have been automatically disabled due to conflicts with subsequentrules, for example, are enabled in the event the subsequent conflictingrules have been disabled in the interim. The MR engine 11 then selectsthe initial rule in the rule set to begin generating the result (step602). A determination is then made as to whether the selected rule isdisabled (step 603), for example, by either an “Undo” operation manuallyselected by the user, or manually disabled by the user upon viewing therule set. If the rule is determined to be disabled (affirmativedetermination in step 603), a determination is made as to whether thecurrent rule set contains any more unprocessed rules (step 607). If so,the next rule will be selected for processing (return to step 602).

If, on the other hand, the selected rule is not disabled (negativedetermination in step 603), a determination is made as to whether theselected rule conflicts with a later rule in the rule set (step 604). Inparticular, when the MR engine is about to execute a rule, it will checkthe dependencies among the rules to determine whether any later rule inthe rule set affects the same result definition(s) in a related way(e.g., also changing the name, or setting the same attribute). If so,the current rule is automatically disabled (step 605) and adetermination is then made as to whether the current rule set containsany more unprocessed rules (step 607). If so, the next rule will beselected for processing (return to step 602).

If, on the other hand, the selected rule does not conflict with a laterrule (affirmative result in step 604), the selected rule will beexecuted and the result updated (step 606). This process is continuedfor all rules in the rule set until all rules have been processed, atwhich time the result will be displayed.

It is to be appreciated that the present invention may be employed tomatch different types of content common to different sets of inputs,whereas other matching tools are engineered to be specific to one typeof input content, for example, matching of text files. Advantageously,the present invention is adaptable to matching, reconciliation andintegration of other types of content, such as the XML situation notedabove. The MR engine can easily be adapted to apply to a variety ofdifferent content types. New types of MR rules can also be easily added.On the other hand, the user interface for each matching type would haveto be somewhat modified, in order to properly reflect the user's modelof the contents being matched for the purposes of combining, mapping, ortranslating the contents of the inputs. However, the basic design ofuser interaction with a user interface, which shows the results of adefault match and the application of a set of rules, in order to add,remove, or modify rules in the persistent rules set, remains the same.The GUI code is well separated from the MR code, allowing GUImodifications to be made without affecting the core system.

It is to be understood that the present invention is not restricted tothe specific process of integrating entities as described above and thatone of ordinary skill in the art can envision a variety of differentsoftware development tools that may be configured in accordance with theteachings herein. In particular, the MR engine of FIG. 1 may beconsidered, in general, as a builder engine which receives an inputcomprising one or more elements (depending on the type of application)to generate desired output elements (in accordance with the applicationtype) using a set of rules that are configured for processing theparticular elements of the desired application and generated (in part)based on user-interactive editing performed via a GUI suitable for thegiven application. For example, with object-oriented design, UML(Unified Modeling Language) may be used for graphically designing anobject-oriented system (e.g., graphically designing classes, methods,instance variable, hierarchical structures of classes, etc). In thissituation, the builder engine may import either existing code (e.g. aC++ file) or a description or representation of an initial graphicaldiagram (e.g., XMI (XML Metadata Interchange)) and generate a diagramwhich is displayed via the GUI for user-interactive editing. Inaccordance with the present invention, such user interactions can berepresented by rules which are stored persistently. If the initial codeor XMI is modified, the user can advantageously have the stored rules(from the prior editing session) applied to the modified input tothereby produce a result which can tailor is necessary.

Although illustrative embodiments have been described herein withreference to the accompanying drawings, it is to be understood that thepresent system and method is not limited to those precise embodiments,and that various other changes and modifications may be affected thereinby one skilled in the art without departing from the scope or spirit ofthe invention. All such changes and modifications are intended to beincluded within the scope of the invention as defined by the appendedclaims.

What is claimed is:
 1. A method for generating a result entity,comprising the steps of: receiving as input at least one input entity;automatically transforming the at least one input entity to a resultentity; displaying the at least one input entity and the result entity;editing the displayed result entity by accepting at least one usercommand, if the result entity is not satisfactory to the user, whereinthe input entity comprises input elements and the result entitycomprises output elements; selecting, by the user, at least one elementof the displayed result entity; and automatically indicating at leastone element of the at least one input entity that corresponds to the atleast one element selected by the user.
 2. The method of claim 1,wherein the step of automatically transforming the at least one inputentity comprises the step of applying a rule set having at least onecomposition rule to transform the at least one input entity to theresult entity; and wherein the step of editing the displayed resultentity comprises the steps of modifying the rule set based on the atleast one user command, and generating and displaying an edited resultentity by applying the modified rule set to the at least one inputentity.
 3. The method of claim 2, further comprising the steps of:repeating the editing step until the edited result entity issatisfactory to the user; and saving to memory the modified rule set andassociating it with the at least one input entity.
 4. The method ofclaim 3, further comprising the steps of: retrieving from memory themodified rule set; applying the modified rule set to a modified versionof the at least one input entity; automatically disabling any rule inthe modified rule set that is rendered ineffective due to the modifiedversion of the at least one input entity.
 5. The method of claim 2,wherein the step of modifying the rule set comprises the steps of:generating at least one composition rule representing the at least oneuser command; and incorporating the at least one generated compositionrule into the rule set.
 6. The method of claim 2, wherein the step ofapplying a rule set comprises the step of one of retrieving a previouslystored rule set and selecting a default rule set.
 7. The method of claim2, wherein the step of applying the rule set comprises the steps of:determining if the rule set includes any disabled rules; and ignoringthe disabled rules during the transform process.
 8. The method of claim2, wherein the step of applying the rule set comprises the steps of:determining if the rule set includes at least one group of conflictingrules; and automatically disabling all rules in the at least one groupthat are recorded earlier than the latest recorded rule in the group. 9.The method of claim 1, wherein the input elements of the at least oneentity and the output elements of the result entity comprises one ofrun-time elements and element definitions.
 10. The method of claim 1,wherein the step of editing the displayed result entity includes one ofapplying a set of default rules to at least one element of the inputentity, specifying a match between elements of the input entities,retracting a match that was found by applying the rule set, adding adesired element to the displayed result entity, deleting an element ofthe displayed result entity, renaming an element of the displayed resultentity, specifying a desired transformation to reconcile input elements,and any combination thereof.
 11. A program storage device readable by amachine, tangibly embodying a program of instructions executable by themachine to perform method steps for generating a result entity, themethod steps comprising: receiving as input at least one input entity;automatically transforming the at least one input entity to a resultentity; displaying the at least one input entity and the result entity;editing the displayed result entity by accepting at least one usercommand, if the result entity is not satisfactory to the user, whereinthe input entity comprises input elements and the result entitycomprises output elements; selecting, by the user, at least one elementof the displayed result entity; and automatically indicating at leastone element of the at least one input entity that corresponds to the atleast one element selected by the user.
 12. The program storage deviceof claim 11, wherein the instructions for performing the step ofautomatically transforming the at least one input entity compriseinstructions for performing the step of applying a rule set having atleast one composition rule to transform the at least one input entity tothe result entity; and wherein the instructions for performing the stepof editing the displayed result entity comprise instructions forperforming the steps of modifying the rule set based on the usercommand, and generating and displaying an edited result entity byapplying the modified rule set to the at least one input entity.
 13. Theprogram storage device of claim 12, further comprising instructions forperforming the steps of: repeating the editing step until the editedresult entity is satisfactory to the user; and saving to memory themodified rule set and associating it with the at least one input entity.14. The program storage device of claim 13, further comprisinginstructions for performing the steps of: retrieving from memory themodified rule set; applying the modified rule set to a modified versionof the at least one input entity; automatically disabling any rule inthe modified rule set that is rendered ineffective due to the modifiedversion of the at least one input entity.
 15. The program storage deviceof claim 12, wherein the instructions for performing the step ofmodifying the rule set comprise instructions for performing the stepsof: generating at least one composition rule representing the at leastone user command; and incorporating the at least one generatedcomposition rule into the rule set.
 16. The program storage device ofclaim 12, wherein the instructions for performing the step of applying arule set comprise instructions for performing the step of one ofretrieving a previously stored rule set and selecting a default ruleset.
 17. The program storage device of claim 2, wherein the instructionsfor performing the step of applying the rule set comprise instructionsfor performing the steps of: determining if the rule set includes anydisabled rules; and ignoring the disabled rules during the transformprocess.
 18. The program storage device of claim 12, wherein theinstructions for performing the step of applying the rule set compriseinstructions for performing the steps of: determining if the rule setincludes at least one group of conflicting rules; and automaticallydisabling all rules in the at least one group that are recorded earlierthan the latest recorded rule in the group.
 19. The program storagedevice of claim 11, wherein the input elements of the at least oneentity and the output elements of the result entity comprises one ofrun-time elements and element definitions.
 20. The program storagedevice of claim 11, wherein the instructions for performing the step ofediting the displayed result entity comprise instructions for one ofapplying a set of default rules to at least one element of the inputentity, specifying a match between elements of the input entities,retracting a match that was found by applying the rule set, adding adesired element to the displayed result entity, deleting an element ofthe displayed result entity, renaming an element of the displayed resultentity, specifying a desired transformation to reconcile input elements,and any combination thereof.
 21. A system for generating a resultentity, comprising: a builder engine for automatically transforming atleast one input entity to a result entity; and a graphical userinterface (GUI) for displaying the at least one input entity and theresult entity and editing the displayed result entity by accepting atleast one user command, wherein when at least one element of a displayedentity is selected, each corresponding element of the displayed entitiesis automatically highlighted.
 22. The system of claim 21, wherein thebuilder engine is a matching/reconciliation (MR) engine which isconfigured for automatically transforming the at least one input entityby applying a rule set having at least one composition rule to transformthe at least one input entity to the result entity; and wherein the GUIis configured for editing the displayed result entity by accepting atleast one user command that is processed to modify the rule set based onthe at least one user command, whereby the MR engine generates an editedresult entity by applying the modified rule set to the at least oneinput entity.
 23. The system of claim 22, wherein the input entitycomprises input elements and the result entity comprises outputelements.
 24. The system of claim 23, wherein the at least one usercommand includes one of applying a set of default rules to at least oneelement of the input entity, specifying a match between elements of theinput entities, retracting a match that was found by applying the ruleset, adding a desired element to the displayed result entity, deletingan element of the displayed result entity, renaming an element of thedisplayed result entity, specifying a desired transformation toreconcile input elements, and any combination thereof.
 25. The system ofclaim 23, wherein the MR engine comprises: means for determining if therule set includes any disabled rules; and means for ignoring thedisabled rules during the transform process.
 26. The system of claim 23,wherein the MR engine comprises: means for determining if the rule setincludes at least one group of conflicting rules; and means forautomatically disabling all rules in the at least one group that arerecorded earlier than the latest recorded rule in the group.
 27. Agraphical user interface (GUI) for editing a result entity that isgenerated by the integration of a plurality of input entities,comprising: an input portion for displaying elements of at least one ofthe input entities; an output portion for displaying elements of theresult entity; and means for selecting, by the user, at least oneelement of the displayed result entity; and means for automaticallyindicating at least one element of the at least one displayed inputentity that corresponds to the at least one selected element of thedisplayed result entity, whereby a user can edit the selected at leastone element of the displayed result entity by selecting at least oneuser command via the GUI.
 28. The GUI of claim 27, further comprising:means for selecting, by the user, at least one element of the displayedinput entity; and means for automatically indicating at least oneelement of the displayed result entity that corresponds to the at leastone input element selected by the user, whereby a user can edit thedisplayed result entity in accordance with the selected at least oneinput element by selecting at least one user command via the GUI. 29.The GUI of claim 28, wherein the at least one user command furtherincludes one of applying a set of default rules to the selected at leastone element of the input entity, specifying a match between selectedelements of displayed input entities, specifying a desiredtransformation to reconcile selected input elements, retracting atransformation that generated the selected element of the displayedresult entity, adding a desired element to the displayed result entity,deleting the selected element of the displayed result entity, renamingthe selected element of the displayed result entity, and any combinationthereof.